Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

Hmm, I raced with your PR, @RalfJung 😅: #98504. At least now we can freely pick between the Arc and the UnsafeCell approaches

This looks like a good fix for the issue. We could look into a solution without an Arc later, although I doubt it matters much.

Thanks!

@bors r+

📌 Commit 846bba4616e70ae9275e947eb450deb7a82f0a79 has been approved by m-ou-se

@bors r-

The PhantomData<&'scope T> in ScopedJoinHandle results in slightly different behavior. It's correct for the variance of 'a, but it makes a difference for dropck.

This snippet errors before this change, but compiles after this change:

use std::thread::ScopedJoinHandle;

fn x<'a>(_: &'a i32, h: ScopedJoinHandle<'a, i32>) -> ScopedJoinHandle<'a, i32> {
    h
}

fn main() {
    std::thread::scope(|s| {
        let mut v = Vec::new();
        {
            let a = 1;
            v.push(x(&a, s.spawn(|| 1)));
        }
    });
}

(Whether that's a real issue.. I'm not sure yet. But it's a publicly visible change, although an extremely subtle one.)

So, was it previously invariant? Or should I replace T by ()?

Looking at the old type, the data under lifetime 'scope is ScopeData. So I switched to that type in the PhantomType. I would think that means the old behavior is preserved?

Yeah, that sounds right. Testing now..

Nope. It still compiles.

That... doesn't make any sense, or does it?

&'scope ScopeData doesn't have a Drop impl. We need something that has 'scope and might use that lifetime in its Drop impl.

The old code doesn't have such a thing either, though?

It did: JoinInner's drop glue could drop a Packet<'scope, T>, which has a Drop implementation without #[may_dangle].

Ah, this should do it. The lifetime needs to be on Packet since that has a impl Drop without may_dangle.